NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/9695

Internet Message Format | 1996-08-05 | 3.9 KB

Path: newshost.netinfo.com.au!usenet
From: Alan Brain <[e-mail]>
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: Re: C/C++ knocks the crap out of Ada
Date: 2 Mar 1996 23:09:41 GMT
Organization: Netinfo Pty Ltd - Canberra Australia
Message-ID: <4hakfl$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: dialup2.dynamite.com.au
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.2N (Windows; I; 16bit)

[e-mail] (Kazimir Kylheku) wrote:


>You are confusing the language specification with the implementation. The C
>specification does not call for the ability randomly access memory. The only
>way to legally manufacture pointers is by taking the addresses of named
>objects, using the standard defined function malloc() or through pointer
>arithmetic (adding an integral displacement to an existing pointer---an
>operation which yields undefined results if you try to create a pointer outside
>of an object). You aren't even legally allowed to subtract two pointers that
>don't reference the same object, even if they have compatible types.

Agree. But if a Cosmic Ray comes and Zapps a bit, this could happen. Or if a
memory chip wasn't quite up to par. Ada 83 will catch it at the next
type-check, raise an exception, and trigger whatever error-correction has been
designed into the program. Yes, if that's insufficient, you have problems.

But in C you carry on, Fat, Dumb and Happy, over-writing God knows what. Bit
of a blow if the program's in control of a Nuclear powerplant. Or a
flight-control system. Could even be nasty if it's the Stock exchange, can
anyone say 'Instant Economic Depression'.

>If C is ``unsafe'', C++ is lethal.

Agree.

>Whether C is more or less unsafe than Ada is truly debatable.  A
>standard-conforming, _quality_ implementation of either language coupled with
>adherent programs subject to rigorous quality control is suitable for
>safety-critical software.

See above example. EVEN IF THE CODE IS BUG FREE ( a big ask IMHO ) there will
occur problems - hardware problems - which the C language cannot detect by its
very nature, and so cannot correct. Ada 83 gives a greater - though not
absolute - ability to the programmer so the program can cope with bugs, hard
failures and soft failures, and STILL work. Sorry, but being able to say to
the relatives 'No fair, it was a cosmic-ray induced glitch, the software was
bug free' cuts no mustard if the plane crashed as the result of an
out-of-index parameter.

To give a concrete example, I - along with some very inexperienced programmers
- recently wrote a Threat Evaluation and Weapon Assignment segment. One which
would kill people if it didn't work exactly right, either by shooting at
friendlies, or allowing a missile through to hit the ship.
When first ported to the target hardware, it ran. Badly. The error log was
going berserk, there were large quantities of minor errors, and 3 major ones.
But it STILL did the job - slowly. Over 95% of its time was spent doing
error-correction and reporting, literally. When the last of the bugs we found
was detected, we'd speeded it up by a factor of over 20. Due to the hardware
we were interfacing with being not quite up to spec (proven) - and probably
other bugs we hadn't found -, the error log was still getting 20-30 errors/sec
(as opposed to 650 ). But it still worked, despite errors that would certainly
have caused Kernel Panic Core Dumped every few minutes if 'twere in C.

That's the key to success in my experience. Ada 83 code cannot be Bug-Free,
but it can be Bug-Resistant. C - except in certain ways, and with an
increase of up to 10 times the coding effort - can't.